What

Four SEA-via-kernel↔Thrift parity fixes surfaced by the Go comparator (two database/sql connections against the same warehouse, differing only in useKernel). All are kernel-path-only divergences from the default Thrift path; every fix is entirely Go-side (no kernel/C-ABI change).

• TIMESTAMP out-of-nanosecond-range wrapping. The kernel Rows path converted arrow timestamps with arrow's ToTime, which forms an int64-nanosecond intermediate (value * unit-multiplier). For a microsecond TIMESTAMP — Databricks' wire unit — that overflows int64 outside ~1678–2262 and silently wraps a valid instant to a wrong one: TIMESTAMP '0001-01-01' scanned back as 1754-08-30, '9999-12-31' as 1816-03-30. Now converts via the unit-specific time.Unix/UnixMilli/UnixMicro constructors, which split into (seconds, nanoseconds) and represent the full 0001–9999 range. The default Thrift path is unaffected — it receives TIMESTAMP as a preformatted server string and never runs this multiply.

• DDL affected-rows reported as -1 instead of 0. The C ABI returns -1 for "not applicable / unknown" affected-row counts (DDL, SELECT, or a warehouse that doesn't surface the counter — the kernel's num_modified_rows Option<i64> None). The Thrift path reports 0 in those cases, so Result.RowsAffected() diverged: a CREATE/DROP SCHEMA returned -1 on the kernel backend vs 0 on Thrift. The -1 sentinel is now folded to 0; a real DML count (>= 0) passes through unchanged.

• User-Agent not forwarded on the kernel path. The kernel backend never forwarded the driver's composed User-Agent, so the kernel's built-in UA leaked through and query history misattributed SEA-path queries. Now forwards the same UA the Thrift path sends via set_custom_header, so both backends are attributed alike. Default-on; WithUserAgentEntry still customizes it.

• VOID/NULL columns reported as NULL instead of STRING. The kernel mapped an arrow.NULL column to DatabaseTypeName="NULL"/nil scan type, but the server stringifies VOID over the Thrift wire — verified live, even a bare SELECT NULL reports STRING_TYPE, same as it does for intervals. So sql.ColumnType diverged between backends for any null/void column. Now maps arrow.NULL to STRING (unbounded length, string scan type), matching Thrift. Also corrects two pure-Go parity tests that had pinned NULL_TYPE — that expectation was derived from the enum name, not captured live, and the live server disagrees.

Testing

• TestScanCellTimestampOutOfNanoRange — pins both TIMESTAMP repro endpoints (0001-01-01, 9999-12-31) plus the int64-ns boundary years; existing timestamp unit/location tests still pass.
• TestNormalizeAffectedRows — table test for the DDL sentinel-normalization rule, in a pure (untagged) normalizeAffectedRows so it runs under the default CGO_ENABLED=0 build.
• TestColumnTypeInfoFor / TestColumnTypeInfoMatchesThriftMapping / TestColumnTypeInfoScanTypeCoversScanner — the VOID→STRING mapping and its two cross-checks against the Thrift functions; all green.
• Verified on both build paths: default pure-Go (CGO_ENABLED=0) and tagged cgo (-tags databricks_kernel, linking the pinned kernel .a) — build + unit tests green on each.
• Comparator run (databricks-driver-test Go comparator, Thrift vs SEA over 108 cases): this PR takes the run from 41 → 14 diffs vs driver main. The TIMESTAMP-range and VOID cases are fully resolved and DDL is down to a lone residual; the remaining 14 are pre-existing and unrelated to this PR (comparator NaN-vs-NaN artifacts, engine-specific EXPLAIN text, a permission-gated CREATE PROCEDURE, kernel feature gaps in arrow-batch fetch / volume staging, and an empty-result-set metadata gap that is a separate kernel-side follow-up).

Stacked on mani/sea-kernel-new-items (#412).

Co-authored-by: Isaac